Troubleshooting
This section offers you solutions, workarounds, and explanations for issues related to CCC.
I’m facing an issue with my CCC container managed by Podman. The container stops unexpectedly after a few hours of inactivity.
The issue occurs because Podman stops the container when the user session becomes inactive. To resolve this, follow the steps below.
Stop and remove the existing CCC container: podman rm -f ccc
Reset Podman settings: podman system reset
Enable linger for the current user to prevent session inactivity: loginctl enable-linger $UID
Linger keeps the user session active even when no one is logged in, which prevents the CCC container from stopping due to session inactivity.
Reload the CCC container images from the installation package for your CCC version. For the application container: podman load -i ccc-4.5.1.tar. For the database container: podman load -i ccc-db-4.5.1.tar
Restart the CCC container, as described here.
I cannot access CCC on Mozilla Firefox even after clicking the Accept the risk and continue button.
This issue is specific to Mozilla Firefox. You can either access CCC on Google Chrome or Microsoft Edge, or follow these steps to access CCC on Mozilla Firefox:
Click the Options tab from the menu on the right.
Click the Privacy and Security option from the navigation pane on left and then scroll down to the Certificates section.
Click the View Certificates button and then click the Servers tab from the Security Manager window that appears on the screen.
Click the Add Exception button at the bottom.
Enter the full CCC URL in the Location field of the Add Security Exception window that appears on the screen.
Click the Get Certificate button and then click the Confirm Security Exception button after the certificate gets generated. You should now be able to access CCC on Mozilla Firefox.
Why am I seeing an error under the Device Status column of the Monitoring and Reports tab after changing the CCC root of trust?
You are seeing this error because you haven't reconfigured the devices after changing the CCC root of trust (ROT). To reconfigure the devices:
Login to CCC and navigate to Devices.
Select the device that is displaying the error under the Device Status column.
Click the Connection tab.
Press the Update Credentials button.
In the Update Rest API Credentials window that appears, enter your username and password and then press the Update button. A pop-up message will appear on your screen, indicating that the credentials have been successfully changed.
Click the Authorization tab and then press the Re-authorize Device button.
In the Authorize SO Login window that appears, enter the HSM SO password to grant CCC the right to login to the device, and then press the Authorize button.
In a short while, the Device Status icon will turn to green and you'll be able to perform the device monitoring tasks. In case you have another device that's reflecting the same error perform the above-mentioned procedure again for that device.
I'm encountering the following error while installing Podman in non-root user mode: Podman run error in non-root mode: "user namespaces are not enabled in /proc/sys/user/max_user_namespaces"
You are encountering this error because either the user namespaces are not enabled or have a limit set that is preventing Podman from running in the non-root mode. To resolve this issue, adjust the value of user.max_user_namespaces by running the following command with sudo privileges:
sudo sysctl user.max_user_namespaces=15000
Increasing the limit on user namespaces will allow Podman to run in non-root mode successfully without encountering the error.
I'm encountering the following error while loading the CCC image when running Podman in non-root user mode: "Potentially insufficient UIDs or GIDs available in user namespace"
You are encountering this error because there are potentially insufficient UIDs or GIDs available in the user namespace. To resolve this issue, run the following commands with sudo privileges:
sudo usermod --add-subgids 10000-75535 <USERNAME> sudo usermod --add-subuids 10000-75535 <USERNAME> podman system migrate
These steps aim to address the issue of potentially insufficient UIDs or GIDs available in the user namespace, allowing Podman to run successfully with the non-root user.
What steps should I take to resolve a root-of-trust issue that has arisen after changing the HSM Admin password for the device used in CCC root-of-trust creation?
This issue occurs because the CCC app container is still using the secret associated with the previous HSM Admin password. To resolve it, restart the ccc-app container as described here, updating the corresponding secret file or Kubernetes/Helm secret as part of that process.
How should I address a root-of-trust issue that arises after updating the Crypto Officer password for the HSM partition I used to establish CCC root-of-trust?
This issue occurs because the CCC app container is still using the secret associated with the previous password. To resolve it, restart the ccc-app container as described here, updating the corresponding secret file or Kubernetes/Helm secret as part of that process.
How should I proceed when facing a root-of-trust issue on CCC following a change in the certificate of the HSM device used for CCC root-of-trust creation?
This issue occurs because the CCC app container is still using the secret associated with the previous certificate. To resolve it, restart the ccc-app container as described here, updating the corresponding secret file or Kubernetes/Helm secret as part of that process.
How do I enable detailed error logs during CCC installation?
If you need detailed error logs while installing CCC, you can turn on debug mode by adding DEBUG_MODE='Y' to the config file and restarting the container. Where you'll find that config file depends on how you installed CCC. If you went with Podman, it's <distribution_package>/ccc-app/podman/ccc_config.env for the ccc-app container, and <distribution_package>/ccc-db/podman/pg_config.env for the ccc-db container. If you used Kubernetes, look for <distribution_package>/ccc-app/kubernetes/configmap.yaml for ccc-app and <distribution_package>/ccc-db/kubernetes/configmap.yaml for ccc-db. If you're on Helm, this option isn't available yet. It's planned for an upcoming release.
Once you've made the change, restart the CCC container as described here.
How should I address the following error that I'm receiving when I try running the ccc_client.jar:
A JNI error has occurred, please check your installation and try again. Exception in thread "main" java.lang.UnsupportedClassVersionError: com/safenetinc/client/LDClient has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
You may receive this error if you are using a version of Java that is not compatible with the latest version of CCC. To ensure that CCC operates smoothly, it's necessary to have Java 21 installed on the computer where the ccc_client.jar file is stored.
Why do my NFS clients freeze during a server outage in a CCC HA setup?
You may encounter this issue if your NFS clients lose their mount stability during a server outage in a high-availability environment. In such cases, the NFS service may not automatically recover, causing client operations to freeze. To restore normal behavior, rerun the enableNFSSharing.sh script on the CCC server to re-establish NFS sharing and allow clients to resume operation.
